home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Magnum One
/
Magnum One (Mid-American Digital) (Disc Manufacturing).iso
/
d21
/
qw12.exe
/
QWHITE12.EXE
/
LOADHI5.TEC
< prev
next >
Wrap
Text File
|
1990-10-08
|
6KB
|
132 lines
ID:LH Loadhi: Recent Versions
Quarterdeck Technical Note
by Joe Wilder
This technote discusses QEMM's Loadhi programs, concentrating on
material which is not already in the Quarterdeck manuals and on
versions of QEMM 5.0 or later. Chapter 5 and Appendix A of the
Quarterdeck expanded memory manager manual contain
the basic Loadhi information.
Q: What does Optimize do?
OPTIMIZE will load TSRs and device drivers high in the most
"optimal" way, sometimes testing millions of different
possibilities. The LOADHI programs available in QEMM version 5
and later can determine the size of particular TSRs or device
drivers and can place them in specific memory address ranges. It
would normally be difficult to use the Loadhi programs
manually to improve on the way Optimize arranges programs
in high memory.
Q: What's Loadhi all about?
There is a popular misconception that PCs using DOS have an
absolute limit of 640K of space to run programs in. Untrue --
there is actually 1024K of addressable code space. The LOADHI
programs are used to run resident programs and device drivers in
the address space between 640K and 1024K. This area is normally
reserved for hardware devices such as video cards, system ROM and
network adapters. Any space in that ramge that isn't occupied by
these devices, Roms, and Ram is just that, empty space. There is
usually more that one. Each of these areas is called a region.
Qemm attaches memory to these empty spaces with a process called
memory mapping creating "High Ram." The more devices you have
that use the address range 640-1024K, the less high memory will
be available to load programs into. Expanded memory managers
also utilize 64K of this upper address space for what is called a
"page frame." The expanded memory page frame is a space through
which programs familiar with the expanded memory standard can get
access to the larger pool of expanded memory.
Q: Can I get rid of the Expanded memory page frame?
The page frame may turned off, and doing so would allow space for
64K more High Ram. The disadvantage to doing this is
that programs that want to use the expanded memory pool could no
longer do so. Therefore, turning off the expanded memory page
frame is only a viable option for users whose programs don't use
expanded memory. The parameter to turn off the expanded memory
page frame is "FRAME=NONE".
Q: Will QEMM and LOADHI load TSRs directly into extended and/or
expanded memory?
Many new QEMM users assume that LOADHI can run TSRs and device
drivers directly in extended or expanded memory. This is not the
case. The only address space where these items can be run is in
what were empty addresses (previous to the installation of Qemm
and the RAM parameter) in the address range from 640K to 1024K.
This is where "High Ram" gets installed using the RAM parameter
of Qemm.
Q: Why am I getting an error message, "No High Memory Available"?
The RAM parameter to QEMM.SYS must be invoked in order to use
LOADHI programs. This attaches some expanded memory to the unused
addresses in the reserved memory area. Once the RAM is
available, programs can be loaded there with LOADHI. If loading
high is attempted without the RAM parameter being specified, the
above error message will appear. Using the RAM parameter to
QEMM.SYS prevents QEMM from being turned off at the prompt.
Q: I seem to have enough High Ram, but my program still won't
load high.
Each program must be loaded into a single contiguous memory area.
Because of this, very large TSRs and device drivers often won't
load high. For instance, if QEMM establishes two high memory
regions, one of 80K, and the other of 32K, a program that
requires 90K to load wouldn't be able to be loaded high. It
would have to fit in one Region or the other. The size and
number of regions varies from computer to computer depending on
the size of the BIOS, the number of devices and where in the 640-
1024K address space these are situated.
Q: Why doesn't my "Largest Available" window size, indicated by
DESQview's Memory Status program, increase when I load my drivers
and TSRs high?
Q: Is there any way of finding just a little more High Ram?
There are some small things you can do that may improve your
available conventional memory. Rearranging your config.sys and
autoexec.bat so that the items that take the most memory come
first often will improve available conventional memory when
Optimize is run. Setting up you hardware devices so that the
available High Ram is large contiguous regions instead of small
fragmented regions will allow Optimize more options in putting
things up high. For example, three 7K regions often aren't as
usable as one 21K area. Changing the address ranges hardware is
accomplished by reconfiguring the hardware itself. Some devices
have jumpers or switches on the card, others are software
configurable. Using the Analyze feature of Qemm will almost
surely find some more places to put High Ram. If this procedure
is used, the instructions must be followed explicitly.
Q: Is there anything special to consider about Loading High for
DESQview users?
DESQview has the capability of running most of its own code in
high memory. You don't have to use the RAM parameter with QEMM
to get this feature. DV.COM (XDV.COM renamed) will map expanded
memory into the available addresses on its own. It will then run
DESQview in that memory. DESQview can use as much as 95K of
reserved memory space. Loading high too many resident programs
and drivers before going into DESQview may cause DESQview to load
more of itself in the lower 640K, resulting in little or no gain
for the largest available window size in DESQview. Sometimes,
because of the different sizes of memory regions available, you
may actually get a slightly larger window size in DESQview by
loading something low instead of high. If you are running
DESQview, it is a good idea to avoid loading "Pop-up" type TSRs
before DESQview at all (using LOADHI or not), but instead put
them in DESQview windows, where their overhead in lower memory
can be completely eliminated.
Copyright (C) 1990 by Quarterdeck Office Systems
* * * E N D O F F I L E * * *